5. The WHEN NOT MATCHED BY SOURCE Clause
The third, and last, merge clause handles deletions, as shown here, followed by the required semicolon terminator:
WHEN NOT MATCHED BY SOURCE THEN
DELETE;
The WHEN NOT MATCHED BY SOURCE clause serves as the exact reverse of WHEN NOT MATCHED BY TARGET
and returns target (replica) rows not found in the source (original)
table. This scenario would occur as the result of removing rows from the
original table after they have been replicated. Rows removed from the
original table need to be removed from the replica table as well, which
is accomplished by the simple DELETE statement in this clause.
Regarding the use of multiple clauses, WHEN NOT MATCHED BY SOURCE has very same rules as WHEN MATCHED. You are permitted up to two WHEN NOT MATCHED BY SOURCE clauses. If you have two, the first one must be qualified with an AND condition. Furthermore, one clause must specify an UPDATE, and the other must specify a DELETE. If two WHEN NOT MATCHED BY SOURCE clauses are specified, MERGE will choose one of them to execute for any given row based on whether the AND condition evaluates to true.
Let’s
get started with some data. Both tables are empty at this point (which
does in fact mean that they are already in sync). Start by filling the
original table with a few rows, as shown here:
INSERT Original VALUES(1, 'Sara', 10)
INSERT Original VALUES(2, 'Steven', 20)
Now call the uspSyncReplica stored procedure to bring the replica table up to date. The first time you call the stored procedure, only the WHEN NOT MATCHED
clause will execute. It will execute twice, actually, once for each of
the two rows to be added to replica table from the original table. The
rows affected count displayed after running the stored procedure conveys
this, as shown here:
EXEC uspSyncReplica
GO
(2 row(s) affected)
Examining both tables now verifies that the replica is synchronized with the original, as shown here:
SELECT * FROM Original
SELECT * FROM Replica
GO
PK FName Number
----------- ---------- -----------
1 Sara 10
2 Steven 20
(2 row(s) affected)
PK FName Number
----------- ---------- -----------
1 Sara 10
2 Steven 20
(2 row(s) affected)
Now perform some more changes to the
original table. A mix of insert, update, and delete operations brings
the two tables out of sync again:
INSERT INTO Original VALUES(3, 'Andrew', 100)
UPDATE Original SET FName = 'Stephen', Number += 10 WHERE PK = 2
DELETE FROM Original WHERE PK = 1
GO
SELECT * FROM Original
SELECT * FROM Replica
GO
PK FName Number
----------- ---------- -----------
2 Stephen 30
3 Andrew 100
(2 row(s) affected)
PK FName Number
----------- ---------- -----------
1 Sara 10
2 Steven 20
(2 row(s) affected)
Invoking the stored procedure once again
brings the two tables back in sync by replicating changes from the
original table to the replica, as follows:
EXEC uspSyncReplica
GO
(3 row(s) affected)
This time, you can see that three rows were
affected as the result of one insert (Andrew), one update (Stephen), and
one delete (Sara). Examining both tables verifies that the replica is
once again synchronized with the original, as shown here:
SELECT * FROM Original
SELECT * FROM Replica
GO
PK FName Number
----------- ---------- -----------
2 Stephen 30
3 Andrew 100
(2 row(s) affected)
PK FName Number
----------- ---------- -----------
2 Stephen 30
3 Andrew 100
(2 row(s) affected)
The MERGE statement supports the same OUTPUT clause introduced in SQL Server 2005 for the INSERT, UPDATE, and DELETE statements. This clause returns change information from each row affected by DML operations in the same INSERTED and DELETED pseudo-tables exposed by triggers. Being able to capture this information in the OUTPUT
clause is often a better choice than capturing it in triggers, because
triggers introduce nondeterministic behavior—that is, you cannot
guarantee that multiple triggers on the same table will consistently
fire in the same order every time. (This is often the cause of subtle
bugs that can be very difficult to track down, and thus triggers should
generally be avoided when possible.)
In addition to the columns of the INSERTED and DELETED pseudo-table, another virtual column named $action is supported when OUTPUT is used with the MERGE statement. The $action column will return one of the three string values—‘INSERT’, ‘UPDATE’, or ‘DELETE’—depending on the action taken for each row. Example 4 shows a slightly modified version of the uspSyncReplica stored procedure that includes an OUTPUT clause on the MERGE statement. The OUTPUT clause selects the virtual $action column and all the columns of the INSERTED and DELETED pseudo-tables so that the MERGE
statement can provide a detailed report of every DML operation it
performs. If you have been following along with the steps for the
previous version, you’ll need to drop everything (the tables and the
stored procedure) first. Then, substitute the implementation of the
stored procedure in Example 3 with the code shown in Example 4 and repeat the same steps.
Example 2-19. Using the OUTPUT clause and $action virtual column with MERGE.
CREATE PROCEDURE uspSyncReplica AS
MERGE Replica AS R
USING Original AS O ON O.PK = R.PK
WHEN MATCHED AND (O.FName != R.FName OR O.Number != R.Number) THEN
UPDATE SET R.FName = O.FName, R.Number = O.Number
WHEN NOT MATCHED THEN
INSERT VALUES(O.PK, O.FName, O.Number)
WHEN NOT MATCHED BY SOURCE THEN
DELETE
OUTPUT $action, INSERTED.*, DELETED.*;Running this modified version of the MERGE statement for the last set of changes in the replication example produces the following output:
$action PK FName Number PK FName Number
------- ----- ------- ------ ----- ------- ------
DELETE NULL NULL NULL 1 Sara 10
UPDATE 2 Stephen 30 2 Steven 20
INSERT 3 Andrew 100 NULL NULL NULL
(3 row(s) affected)
This output shows all the actions taken by the merge and all the before-and-after data involved. Of course, you can use OUTPUT…INTO instead of just OUTPUT like you can with the INSERT, UPDATE, and DELETE
statements to send this information to another table for history
logging or additional processing. And concluding our treatment of MERGE, you’ll learn about the INSERT OVER DML syntax introduced in SQL Server 2008 that provides even greater flexibility.
7. Choosing a Join Method
SQL Server is very smart about examining MERGE
statements, analyzing different combinations of merge clauses, and
automatically performing the appropriate type of join to return the
source and target data needed on both sides of the operation. There are
four types of joins, and SQL Server cleverly picks the right one for the
job based on the merge clauses that it finds in the MERGE statement, as shown in Table 1.
Table 1. Source-to-target table join types chosen by SQL Server based on your merge clause(s)
Merge clause | Join type | Returns | Valid actions |
|---|
WHEN MATCHED | Inner | Matching data in both source and target | Update, delete |
WHEN NOT MATCHED [BY TARGET] | Left outer | Source data not found in target | Insert |
WHEN NOT MATCHED BY SOURCE | Right outer | Target data not found in source | Update, delete |
WHEN NOT MATCHED [BY TARGET] combined with any other clause | Full outer | Source data not found in target, and other matching or nonmatching target data | Insert, update, delete |
The WHEN MATCHED
clause returns rows that are found in both tables (that is, rows in
both tables with matching values in the joining key columns defined with
ON). The query processor treats this as an inner join, because you are retrieving only rows that exist on both sides. Either an UPDATE or a DELETE operation on matching target rows is permitted in the WHEN MATCHED clause.
WHEN NOT MATCHED [BY TARGET] is treated as a left outer join, because it retrieves only source rows that do not exist in the target. Therefore, only an INSERT can be performed in the WHEN NOT MATCHED [BY TARGET] clause to “fill the hole” in the target with the missing source data.
The WHEN NOT MATCHED BY SOURCE clause is the complement to WHEN NOT MATCHED [BY TARGET] and results in a right outer join to retrieve only target rows that do not exist in the source. As with WHEN MATCHED, you can perform an UPDATE or a DELETE operation on those target rows missing from the source.
Last, combining WHEN NOT MATCHED [BY TARGET]
with either or both of the other two clauses retrieves source data not
found in the target as well as target data found or not found in the
source. In this case, a full outer join is performed between the two
tables. You can perform an INSERT in the WHEN NOT MATCHED [BY TARGET] clause to add source data missing from the target and an UPDATE or DELETE in the other clause(s) to modify or remove target data.
Important
The only valid statement in WHEN MATCHED or WHEN NOT MATCHED BY SOURCE is UPDATE or DELETE, and the only valid statement in WHEN NOT MATCHED [BY TARGET] is INSERT. No other T-SQL statements (including stored procedure calls) are allowed in any of these merge clauses. However, the INSERT and UPDATE statements in a merge clause are permitted to reference user-defined functions.
As you’ve just learned, the MERGE statement combines the four separate DML statements (SELECT, INSERT, UPDATE, and DELETE) involved in a merge operation. The actual internal implementation of MERGE
is the same as the distinct DML statements it encapsulates. This was a
good call by Microsoft, because it means that developers can begin using
MERGE right away to leverage its improved performance and lower maintenance benefits, without concern for breaking any existing code.
All AFTER and INSTEAD OF
triggers that have already been defined in existing tables or
updateable views continue to fire when those tables or updateable views
are designated as the target of a MERGE statement. For example, the WHEN NOT MATCHED THEN…INSERT clause fires any insert triggers defined for the target; similarly, the WHEN MATCHED THEN…DELETE clause fires delete triggers. There is no concept of a “merge trigger,” so it’s safe for you to immediately start using MERGE in your T-SQL code. Triggers will fire just the same as if you used separate statements instead of MERGE. Existing business logic, constraints, and rules all continue to function as they did before.
The same options and features you are accustomed to using with the separate DML statements are also available with MERGE. For example, you can use a CTE for the source of a merge by defining it using the WITH clause before the MERGE statement and then referencing it with the USING clause. The TOP
clause is similarly supported, as are traditional query hints. And of
course, both source and target tables can be aliased with AS just like tables in regular queries can.
You can see how SQL Server internally implements the MERGE
statement for the stored procedure that handles table replication by
examining the database engine’s query execution plan, shown in Figure 1.
The work begins by scanning the source and target table (query plans are read from right to left). At the right of Figure 1, you can see the advantage of having created indexes on the columns joining the Original and Replica
tables for the merge. Because the join predicate uses the primary keys
of both tables, the query optimizer uses a clustered index scan for the
best possible read performance. You should therefore always create an
index (possibly clustered and ideally unique) on the joined columns used
for merging two tables.
The plan also reveals that a full outer join is performed between the two tables, as shown in the center of Figure 1. As mentioned earlier, the type of join used depends on which WHEN…THEN merge clauses are (or aren’t) specified in the MERGE statement. In this case, SQL Server performs a full outer join because the MERGE statement uses all three of the possible merge clauses. The clustered index merge operation that follows (at the left of Figure 1)
implements the predicate on the first merge clause that selects
matching rows only if any of the nonkey columns have changed between the
original and replica tables.
The clustered index merge consumes
the stream delivered by the full outer join and decides on a row-by-row
basis whether the row being passed to this operation should be processed
as an update, an insert, or a delete, based on the syntax of the MERGE statement and the data in the source and target tables.
